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(Abstract)Case-based reasoning is an approach to problem solving and learning that has got a lot of attention over the last 
few years. This paper provides an overview of the case-based reasoning, brief outline on applicability of case-based 
reasoning to test suite, describing the various features of adaptive test suite system based on CBR framework will possess, 
focuses on benefits of adaptive approach over existing test case selection/retrieval approaches. The current work 
demonstrates the benefit of case base in reasoning approach for selecting test case or for testing the product during system 
testing and regression testing phases of the product. 
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INTRODUCTION 

In Case Based Reasoning, problems are solved by adapting 
the solutions of similar previous cases stored in a case 
memory. CBR mainly consist of four phases they are Retrieve, 
Reuse, Revise, and Retain. [1] Retrieving the cases from the 
case base whose problem is most similar to the new problem. 
Reusing is the solutions from the retrieved cases to create a 
proposed solution for the new problem. Proposed solutions 
are revised to take into account of the problem differences 
between the new problem and the problems in the retrieved 
case. Retaining the new problem and its revised solution as 
new case for new case for case-base if appropriate. CBR is 
having assumptions, first and main assumption is that 
"Similar problems have similar solutions". And other 
assumptions are "The world is a regular place"- what holds 
ttue today will probably hold true tomorrow. Next is 
"Situation repeat"- if they do not there is no point in 
remembering them. 

Test suite is a collection of test cases that intended to be 
used to test a software program to show that it has some 
specific set of behaviors. A Test case is representation of test 
scenarios. A test suite comprises of detailed instructions or 
goals for each collection of test cases and information on the 
system configuration to be used during testing. The main 
conttibution of the work is Classification of techniques for R4 
phases in CBR, Test suite optimization, Case Based reasoning 
and Test suite optimization. 

Markovitch & Scott proposed a unifying framework for the 
systematic discussion of various strategies for coping with 
harmful knowledge in general, and the case of utility problem 
in particular. The framework is based on various types of 
filters for eliminating harmful knowledge at various stages in 



the problem solving procedure. An approach that is especially 
relevant in CBR is to simply delete harmful cases from the 
case base so that they cannot actively contribute to ongoing 
problem solving costs deletion policies in CBR correspond to 
selective retention filters in the Markovitch & Scott 
framework. Surprisingly, in many speed-up learners the 
apparently naive random deletion of knowledge items (to 
maintain the knowledge base to some predefined size) works 
quite well for optimizing efficiency. Even though random 
deletion eliminates both useful and redundant items it can 
equal the success of more sophisticated methods. 

Overview of Case-Based Reasoning: 

The processes involved in CBR can be represented by (Fig-1). 
Aamodt and Plaza described a CBR typically as a cyclical 
process comprising the four steps: 
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Fig-1. The CBR Cycle 
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• RETRIEVE the most similar case(s); 

• REUSE the case(s) to attempt to solve the Problem 

• REVISE the proposed solution if necessary, and 

• RETAIN the new solution as a part of a new case. 

A new problem is matched against cases in the case base and 
one or more similar cases are retrieved. A solution suggested 
by the matching cases is then reused and tested for success. 
Unless the retrieved case is a close match the solution will 
probably have to be revised producing a new case that will 
be retained. 

Few Important terminologies related to CBR are as follows: 
Case Representation: 

A case is a contextualized piece of knowledge representing 
concerned experience or knowledge. It stores the past lesson 
that is the content of the case and the context in which the 
lesson is to be used. Typically a case comprises of following: 

• problem describes the state of the world when a scenario 
case occurs, 

• solution which selects the derived solution to a problem, 
and/or 

• outcome describes the state of the world after the case 
occurrence. 

• Indexing 

Case indexing involves assigning indices to cases for 
alleviating case retrieval. Indices should follow few 
properties: 

• predictive, 

• address the purposes of case usage, 

• allows for widening the future use of the case-base, and 

• be sufficient enough for usage in future 

Both manual and automated methods are used in index 
selection. Selection of indices manually involves deciding a 
case's purpose with respect to the aims of the reasoner and 
deciding under what circumstances the whether the case will 
be used. 

Despite the success of many automated methods, it is 
believed that people tend to do better at choosing indices than 
algorithms. 
Induction 

Induction algorithms (e.g. ID3) determine which features does 
the best job in differentiating cases, and generate a decision 
tree type structure for organizing the cases in memory. This 
approach is better when a single case feature is required as a 
solution, and where that particular case feature is depends on 
others. 
Adaptation 

Once a matching case is retrieved a CBR system should adapt 
the solution stored in the retrieved case to the current case 
needs. Adaptation identifies prominent differences between 
the retrieved case and the current case and then applies 
formulae or rules that are taken into account when 
suggesting a solution. In general, there are two kinds of 
adaptation in CBR: 

• Structural adaptation, in which adaptation rules are to be 
applied directly to the solution stored in cases. This kind 
of adaptation is followed with JUDGE and CHEF. 

IJCSA Volume 1, Issue 1 August 2012 PP. 1-5 www.ij-i 



IJCSA 

• Derivational adaptation, that reuses the algorithms, 
methods or rules that generated the original solution to 
produce a new solution to the current problem. In this 
method the planning sequence that constructed that 
original solution must be stored in memory along with the 
solution as in MEDIATOR. 

An efficient CBR system requires both structural adaptation 
rules to adapt poorly understood solutions and derivational 
mechanisms for adapting solutions of cases that are clearly 
understood. 

Few case based reasoning adaptation techniques are as 
follows: 

• Null adaptation 

• Parameter adjustment 

• Abstraction and respecialisation 

• Critic -based adaptation 

• Re-instantiation 

• Derivational replay 

• Model-guided repair 

• Case-based substitution 

TEST SUITE: 

In software development, a test suite, less commonly known 
as a validation suite, is a collection of test cases that are 
intended to be used to test a software program to show that it 
has some specified set of behaviors. A test suite often 
contains detailed instructions or goals for each collection of 
test cases and information on the system configuration to be 
used during testing. A group of test cases may also contain 
prerequisite states or steps. [8] 
Test suite reduction problem: 

The first formal definition of test suite reduction problem 
introduced in 1993 by Harrold et al. as follows: Given, {tl, 
t2,..., tm] is test suite T from m test cases and {rl, r2,..., rn] 
is set of test requirements that must be satisfied in order to 
provide desirable coverage of the program entities and each 
subsets {Tl, T2,..., Tn) from T are related to one of ris such 
that each test case tj belonging to Ti satisfies ri. 

Problem. Find minimal test suite T from T which satisfies 
all ris covered by original suite T. 

Generally the problem of finding the minimal subset T, T 
is subset of T which satisfies all requirements of T, is 
NP-complete, because we can reduce the minimum set-cover 
problem to the problem of test suite minimization in 
polynomial time. Thus, researches use heuristic approaches to 
solve this problem. 

Related work in the context of test suite reduction can be 
classified into two main categories: The works in which a new 
technique is presented and empirical studies on the previous 
techniques. The works proposed earlier focused includes 
heuristic algorithms, genetic algorithm-based techniques and 
approaches based on integer linear programming. In a recent 
study, four typical test suite reduction techniques have been 
evaluated and compared on 1 1 subject programs. Based on the 
results, this study suggests that the heuristic may be the first 
choice when selecting from the test case reduction techniques, 
.org © Science and Engineering Publishing Company 
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Testing criteria are defined to help the selection of subsets of 
the input domain to be covered during testing. For example, a 
code coverage criterion provides test suite adequacy with 
respect to coverage of the program entities and also provides a 
check on its quality. Assuming testing criterion C which 
satisfies by the test suite T, a test case, f, is redundant if the 
suite T-{t] also satisfies C. Therefore, removing those test 
cases which are redundant with respect to some specific 
criteria preserves test suite's adequacy with respect to that 
criteria. In previous empirical studies researchers commonly 
applied various code coverage criteria in their reduction 
techniques. The results of empirical studies demonstrate that 
the percentage of the test suite size , reduced the percentage of 
faults. Usually a test suite reduction technique attempts at 
removing redundancy among test cases and retain the most 
effective test cases into the test suite. Effective test cases are 
those that satisfy most of the requirements as well as exposing 
the most of the existing faults. Note that the more 
requirements are satisfied, the more execution paths within 
the program would be exercised which yields the all kinds of 
the faults to be exposed. 
TEST CASE CLASSIFICATION: 

System test cases cover the application from end to end. It is 
not based on the requirements given by the client. We need to 
cover the whole application. Test cases were classified into 
different types: 

Graphical user interface testing 
Usability testing 
Performance testing 
Compatibility testing 
Error handling testing 
Load testing 
Volume testing 
Stress testing 
Security testing 
Scalability testing 
Sanity testing 
Smoke testing 
Exploratory testing 
Ad hoc testing 
Regression testing 
Reliability testing 
Installation testing 
Maintenance testing 
Recovery testing and failover testing. 

L Applicability of case-based reasoning to test suite: 

The Case Based Reasoning as such can be tailored to meet the 
necessary condition for test suite reduction. The four Phases 
involved can be designed as below: 

Retrieve: The retrieval case can only proceed once there is 
a proper structure storing the desired case in required format 
suitable for retrieval. In this direction a tree based approach is 
designed for the case. A partial DC tree is given in Fig-2, a 
Decision and Classification tree is constructed. A DC tree 



comprises of system test cases arranged based system artifacts 
of the following (typical but not restricted to): 

• Type of system testing 

• Modules of the system 

• Dependency between modules 

• Interfaces involved 

• Classes involved 

• Dependency between classes, etc.. 

In Case based reasoning the cases are constructed based on 
the above defined artifacts as attributes. The system test cases 
obtained from requirements are arranged as the separate case 
in low order of the tree. In fact a tree is constructed based on 
the above attribute and values. A system test case can fall 
under a particular system testing, module of a system, 
dependency between modules, interface, classes involved, 
dependency among classes and so forth which can be sub case 
for the major case. 
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Fig-2: Partial DC Tree 

Specifically the test cases can be decided by the tester of the 
system test cases when he is performing it manually. 
Anyways this CBR approach will help in identifying the test 
cases based on the specified details like the following. A 
particular objective of system testing may be selected by the 
tester of system test cases and this will list out all the system 
test cases required for fulfilling the particular objective. On 
further clarity/querying in information provided by the 
tester like the modules of the system to be tested, Dependency 
between modules, interface, classes involved, dependency 
among classes and so forth the retrieve can result in 
identifying a proper test case of choice which the tester may 
be looking for. In detail, further approach can be extended to 
index system test cases based on a system test case Identifier, 
which comprise of all the attributes forming the case. In this 
case the identification can be very easy for classification. Also 
any new case can be added further. Fig-3 signifies the same. 




Fig-3: phases of the Test Suite Optimization based on Case Based Reasoning 
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Reuse The retrieved set of test case forms a basis for the 
current scenario can also be taken up as a new case or sub 
case as defined previously. Any set of system test cases that 
are previously tested can also be used during regression 
testing. The result of system test can be any one of the 
following passed, failed, not yet tested. The system test cases 
which were previously distinguished as a test case can be 
reused again, thereby reusing test cases. 
Revise: The revision involves the testing of system test cases 
manually or automatic testing and thereby changing the status 
to one of the following states ie. Tested or not tested again 
tested can have two more sub states like tested but passed, 
tested but failed. The test cases can be revised among them so 
that not only test case states can be changed but tne cases can 
be added, duplicate system test cases can be eliminated, new 
cases can be added and so on. 

Retain: The test cases which were revised earlier can now 
form a part of newly created case/sub case or a old case/sub 
case being created. This can further be updated in the DC tree 
mentioned in earlier stage of DC tree. 

ii. Features of adaptive test suite system based on 

CBR framework: 

The Intended adaptive test suite system acts as a repository 
where System test cases are arranged in form of DC tree. The 
designed system along with DC tree is accessible to 
Tester(s). Tester who requires to test a system under 
development has to specify details regarding the following: 

• Type of system testing 

• Modules of the system 

• Dependency between modules 

• Interfaces involved 

• Classes involved 

• Dependency between classes, etc 

Based on more and more details a tester specifies out of the 
above (because test cases are arranged in above format only in 
the DC tree). The system is capable of doing the following: 

Test case Selection and Reduction 

The adaptive system can guide a tester in selection of test 
cases, when he is specifying the type of testing type of system 
testing, modules of the system, dependency between modules, 
interfaces involved, classes involved, dependency between 
classes, etc.. The selected test cases are reduced by complexity 
of number of branches of tree at any given level in DC tree. 
Store the case history of 'Tester(s). 

• A Tester arriving at the untrained system can select all the 
available test cases that the CBR system suggests, later on 
the tester starts specifying the type of testing type of 
system testing, modules of the system, dependency 
between modules, interfaces involved, classes involved, 
dependency between classes, etc.. 

• More details the tester specifies he narrows down on the 
number of test cases in hand for the tester for selection. 

• The entire history of the test case selection is stored in 
case base under a specified case name specified by Tester 
(name being a non-significant identifier). 
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• On further testing scenarios which are not relevant to 
existing cases in case base, new cases are stored in case 
base. 

• If a relevant scenario of testing happens to be repeated by 
any current tester, which is already in case base, the 
adaptive system comes into being suggesting few other 
matching cases by previous testers. Now the current tester 
can opt to select a new set of system test cases or a 
previously used set of case, which is suggested by the 
adaptive system. 

Most Frequently Tested cases/Scenarios/Modules/bugs 
Based on number of times a test case a particular stored test 
case in case base is being accessed, frequency can be assigned 
to test cases as such the help in understanding the importance 
of test case for testing of module/interface. Hence frequency 
of execution of case(of case-base)/test 
case/Scenario/module/bug verification is notified based on 
frequency count being assigned to test case , whenever it is 
accessed/deemed more frequently by the tester. 
Test case Prioritization 

Test case prioritization techniques schedule test cases for 
execution in an order that attempts to increase their 
effectiveness to meeting some performance goal. Such a 
case-wide sequence of test case can be notified from weight 
age methods, sequencing method etc.. which are few of 
prioritization techniques that are supported. Also they can 
represent severity of defects/test cases. Such test cases can 
really help during sanity/release testing of modules to the 
client. Lesser critical tester (resource) involvement is required 
even critical release of product to client, which may reduce 
project costs. Any of familiar priority based technique may be 
used for this case. 
Test case based Metric Evaluation 

Following are few test case metrics that can be evaluated 
using the above specified module in adaptive test case 
Conceptual System: 

• Functional or Test Coverage Metrics. 

• Software Release Metrics. 

• Software Maturity Metrics. 

• Reliability Metrics. 

These metrics are helpful in deciding the type of testing 
required, type of bugs found during test, severity of bugs, 
stability of module etc. 
Defect Prediction 

The test cases and the corresponding results help in 
identifying the defects in classes, modules, interfaces, system 
testing etc.. A Naive bayes or equivalent approach may 
suggest or help in concluding the defect prediction. 

Regression testing scenarios 

The basic feature of adaptivity to test cases is effective 
during regression testing, because they help in identifying the 
particular type of testing/test case required to test the 
module/class etc. .A tester can get significant help during 
regression testing while it suggests about results of test cases 
previously tested, any modular changes affecting the test case 
results may easily be notified to the tester, which is significant 
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help to tester and improves productivity. A detailed 
discussion can correlate to a separate project on itself. 




Fig-4 Conceptual System for Adaptive Test suite with few features 

Above specified features form a Conceptual System for 
adaptive test suite optimization. 

iii. Benefit of case base in reasoning approach for 

selecting test cases 

Case based reasoning approach is based on the fact on how 
human beings think. Case base in adaptive test suite has the 
following features: 

• Storage of test cases used by tester. 

• Storage of testers experience in form of case in case base. 

• Storage of test case results for the already tested set of test 
cases for a module. 

• Deciding the mechanism for test case selection. 

• Assigning priority of test cases. 

• Deciding the modules to be tested. 

• Making Defect predictions in projects. 
CONCLUSION AND FUTURE WORK: 

In this paper, we described about the Case Base Reasoning 
and the phases involved in it, features that can be used with 
adaptive test suite optimization, benefits of test case base etc.. 
Further with respect to any decision tree based System test 
case selection algorithm can be used. The same adaptive 
technique can further be used to suggest the type of test case 
selection algorithm to be used for a particular type of system 
test case selection. A detailed discussion on this can further 
formulate a approach of case based reasoning applied to 
choosing a test case selection, prioritization method selection 
for a particular domain of product under development 
viz.. embedded, Web based, SAP based, Cloud based etc.. 
Each feature specified in attachment with adaptive test suites 
can further promulgate to individual research items in 
themselves for various domains of Projects under 
development. Regression is vast feature out of the above that 
can be exploited to maximum extent. 

A Work of this nature is essential in wake of tools present 
for generation, execution of tools already available, but this 
work focuses on transfer of human knowledge, expertise, 
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testing based on results of previous version of test cases 
executed, effective resource utilization(tester) in wake of 
reduced and effective execution of reduced set of test cases. 
This will further reduce testing costs to a greater extent in 
combination with other approaches already suggested by 
many other researchers. 
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